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Implementation  of  Parnas'    it-ti  Construct  in  LIS? 
A.  Cain  eanroles 


Abstract 

D.  I.  Parnas  has  recently  proposed  [l]  a  new  programming  control 
structure  -  the  it-ti.  This  construct  is  a  synthesis  of  several 
ideas  in  programming  theory  including  iteration,  conditionals, 
and  Dijkstra's  guards  1 2].  It  has  been  implemented  in  a  LISP 
interpreter  |_8J  as  a  more  structured  replacement  for  the  tradi- 
tional prog  construct.  Several  programming  examples  are  given 
that  compare  the  use  of  the  it-ti  with  the  more  conventional  pro- 
gramming constructs.  These  examples  will  also  show  that  the  it- 
ti  fails  to  satisfy  several  criteria  for  programming  constructs 
including  manageability  and  visibility.  An  appendix  to  this 
report  contains  an  extension  of  Dijkstra's  concept  of  the  'weak- 
est precondition'  to  the  it-ti. 


1  .  Introduction 

D.  L.  Parnas  [1]  has  recently  proposed  a  new  programming  control 
structure  he  calls  the  it-ti  (iteration)  construct  after  the 
fashion  of  do-od ,  if-f i ,  and  case-esac.  It  is  a  synthesis  of  two 
concepts  of  structured  programming  (iteration  and  conditional 
execution)  and  is  a  direct  descendant  of  Dijkstra's  do-od  and 
if-fi  [2].  Reference  [1]  contains  a  detailed  and  mathematical 
treatment  of  the  new  construct  for  both  non-deterministic  and 
deterministic  programming. 

While  the  it-ti  is  certainly  an  interesting  proposal  and  has 
filled  a  niche  in  Navlisp,  we  will  see  that  it  fails  to  satisfy 
several  requirements  of  good  programming. 

To  motivate  the  new  construct,  let  us  look  at  one  of  the 
thorns  of  structured  programming  [3]:  the  mid-exit  loop,  illus- 
trated by  a  sequential  array  search.  The  task  is  to  find  an  ele- 
ment X  in  an  array  A.  If  it  is  found,  function  P  is  passed  the 
index  of  an  element  of  A  that  contains  X.  If  it  is  not  found, 
function  N  is  called  with  X  as  its  parameter.  A  straight- 
forward, non-structured  implementation  in  pidgin-code*  of  this 
task  might  be: 


*  Py  pidgin-code  we  mean  to  indicate  a  language  that 

incorporates  features  of  several  languages,  and  that  we  are 
free  to  modify  as  the  need  arises. 


index  :=  1 ; 
loop:     if  (index  >  sizecf'.V  ,  then  goto  notfound; 

if  (A[ index]  =  K)  then  goto  found; 

index  :=  index  +  1 ; 

goto  loop; 
notfound:  N(K); 

goto  continue; 
found:    7' index); 
continue: 

As  Knuth  [3]  points  ouz,  there  is  really  no  satisfactory  way  to 
solve  this  problem  with  'structured'  programming.  If  we  restrict 
ourselves  and  do  not  use  any  goto  statements,  we  might  solve  the 
problem  in  one  of  the  following  ways: 

Solution  J_ 

found  :=  false; 
for  i  :=  1  to  sizeof(A)  do 
if  (A[i]  =  K)  then 
found  :=  true; 
index  :=  i; 
endif ; 
endfor; 
if  (found) 

then  P( index) ; 
else  N(K) ; 
endif; 

Solution  2_ 

found  :=  false; 

index  :=  1 ; 

while  (not  found  and  index  <=  sizeof(A))  do 

if  (A[ index]  =  K)  then  found  :=  true; 

else  index  :=  index  +  1 ; 

endwhile; 
if  (found)  then  ?( index); 

else  N(K); 

endif; 

Solution  3 


-      7 

while  (index  <=  sizeof(A)  cand  A[ index]  <>  K)  do 

index  :=  index  +  1  ; 
if  (index  >  sizeof(A))  then  N(K); 
else  F( index) ; 

Solution  1  is  obviously  inefficient.  The  whole  array  is  searched 
even  if  K  is  the  first  element.  This  could  be  an  important  con- 
sideration if  the  array  A  is  large.  Solution  2  is  somewhat 
better,  but  the  truly  efficiency-minded  point  out  that  found 
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carries  redundant  information,  is  checked  unnecessarily  in  the 

loop,  and  has  to  be  checked  again  out  of  the  loop.  Solution  3 
removes  the  variable  but  iepends  on  conditional  evaluation  of 
boolean  expressions.  That  is,  the  right-hand  expression  of  a 
3|nd  is  evaluated  only  if  the  left-hand  expression  evaluates  to 
true.  In  our  example  the  cand  prevents  us  from  exceeding  the 
array  bounds  of  A.  Even  so,  this  solution  still  checks  the  value 
of  index  twice:  once  in  the  boolean  expression  of  one  while ,  and 
again  uocn  exit  from  the  while  to  ietermine  why  the  loop  ter- 
minated . 

Note  that  the  usual  response  to  these  criticisms  is  "Who 
cares?",  .and  that  is  the  correct  response  99^  of  the  time.  The 
readability  and  maintainability  of  code  must  take  precedence  over 
efficiency  almost  all  of  the  time.  However,  occasionally,  a 
piece  of  code  will  occupy  a  critical  position  (e.g.  in  an  inner 
loop)  and  the  question  becomes  important.  Again,  the  usual 
response  is  "Code  it  in  .assembly  language".  But  this  implies 
that  readability  and  maintainability  must  be  sacrificed  in  some 
s iTiations  for  efficiency.  A  more  desirable  goal  is  a  set  of 
structured  programming  disciplines  that  promote  readability  and 
maintainability  without  sacrificing  efficiency. 

The  Zahn-construct  [3>4]  attempted  to  solve  this  problem 
with  an  escape  mechanism.  The  following  implements  the  array- 
search  with  a  Zahn  construct  (using  the  notation  of  Xnuth  [3])« 

index  :=  1  ; 

loon  until  found  or  notfound: 
"if  (A[ index]  =  K)  then  found; 
index  :=  index  +  1 ; 
if  (index  >  sizeof(A))  then  notfound; 
repeat ; 

then  found    =>  ?( index); 
notfound  =>  N(X); 


—  * 


Some  find  this  less  satisfying  than  orthodox  structured  program- 
ming or  programming  with  goto  statements.  Some  of  the  problems 
with  the  Zahn-construct  derive  from  the  structure's  lack  of  visi- 
bility and  readability.  For  example,  to  trace  the  results  of  a 
particular  event,  (e.g.  found)  the  reader  must  scan  the  then 
clause  for  the  event  label  -  the  target  of  the  event  -  much  .as  he 
would  have  to  scan  for  the  target  of  a  goto.  While  some  of  these 
problems  might  be  resolved  with  appropriate  syntactic  'sugar', 
the  Zahn-construct  is  still  a  not-very-well  disguised  goto, 
replete  with  label.  This  can  be  appreciated  better  by  drawing  the 
control  flow  graphs  for  the  if-then-else ,  repeat-until,  etc.,  and 
comparing  them  with  the  control  flow  graph  for  the  Zahn-construct 
(q.v.  section  3,  below):  the  Zahn-construct  does  not  have  a  sim- 
ple flow  graph.  About  its  only  advantage  is  that  the  Zahn- 
construct  forces  the  programmer  to  locally  declare  the  labels  in 
the  context  of  use. 


_~_ 


?he  It-ti    Construct 


i 


Farnas  has  proposed  a  generalization  of  Dijkstra's  do-od  .itera- 
tion) and  " if-f i  (conditional)  constructs.  The  basic  syntax  of 
the  it-ti  is  given  below  in  a  close  facsimile  of  Parnas'  nota- 
tion* where  <break/repeat>  represents  one  of  the  keywords  break 
or  repeat. 


p1  ->  s1  <break/ repeat > 
p2  ->  s2  <break/ repeat > 
p3  ->  s3  <break/repeat> 


ti 


pn  ->  sn  Cbreak/ repeat > 


The  semantics  of  the  it-ti  are  straightforward.  The  predicates 
pi  are  evaluated  sequentially  until  one  evaluates  to  true.  If  pi 
is  true,  then  the  sequence  of  statements  sj  are  evaluated.  The 
last  element  of  sj  is  a  keyword  that  specifies  whether  the  it-ti 
is  to  be  executed  again  (repeat),  or  exited  (break).  It  is  an 
error  if  none  of  the  predicates  pi  evaluate  to  true:  in  this 
case,  the  program  aborts. 

The  following  shows  how  an  it-ti  could  be  coded  in  a  conven- 
tional programming  language  likeTascal ,  Algol,  or  FORTRAN. 

it head: 

if  (n1  )  then  begin 

s1; 

goto  <label>;  j  where  <label>  is  ithead  (a  repeat)   j 
I  or  ittail  (a  break)   j 

end 
if  (p2)  then  begin 

32; 

goto  <label>; 

end 


if  (pn)  then  begin 

sn; 

goto  <label>; 

end 
error  ("it-ti  fall  through"); 
ittail: 

{rest  of  program! 


*  The  notation  in  this  report  differs  from  Parnas  in:  (1)  no 
elseor  -  the  predicates  are  assumed  to  be  executed 
leterministically  and  sequentially;  (2)  no  up  and  down  arrows 
-  the  keywords  repeat  and  break  are  used  instead. 
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The  array  search  problem  might  be  implemented  using  the  it- 
ti  as  follows. 

index  :=  1 ; 

it 

index  >  sizeof(A)  ->  .](K);   break; 

A[ index]  =  K     ->  7( index);  break; 

true  ->  index  :=  index  +  1;  repeat; 

ti 

This  seems  to  solve  most,  if  not  all,  of  the  problems  we  have 
mentioned:  there  is  no  redundant  boolean  variable  like  'found'; 
the  search  stops  when  the  element  is  located;  there  are  no  redun- 
dant tests;  there  are  no  labels  that  redefine  the  'shape'  of  the 
structure;  the  targets  of  the  gotos  implied  by  the  repeats  and 
breaks  are  visible  and  fixed;  and  any  compiler  worth  its  salt  can 
factor  out  the  constant  boolean  expression  at  code-generation 
time.  Here  we  have  a  tight,  efficient  sequence  of  code. 


The  traditional  control  structures  are  available  using  the 


it-ti . 


if- then-else : 


if  (b)  then 
(bodyl  ) 

else 

(body2) 

endif 


it 


ti 


b    ->  bodyl ;  break; 
true  ->  body2;  break; 


for-looo: 


for  i  :=  1  to  n  do 
(body) 
end; 


i  :=  1; 


i  <=  n 


;rue 


->  (body)  ; 

i  :=  i  +  1 ; 

repeat ; 
->  break; 


it 


while-loon: 


while  (b)  do 
(body) 
end; 


it 


ti 


b    ->  (body);  repeat; 
true  ->  break; 
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case-statement : 


case  x  of 

x1  :  bodyl  ; 
x2:  body2; 

xn:  bodyn; 
en  :: 

repeat-loop: 

repeat 

(body) 

until  b; 


It 


fci 


it 


ti 


x  =  x1  ->  bodyl ;  break; 
x  =  x2  ->  body2;  break; 

x  =  xn  ->  bodyn;  break; 


init  or  b  ->  (body);  repeat; 
true     ->  break; 


3-  Evaluation  of  the  it-ti 

There  are  several  valid  criticisms  of  the  it-ti .  For  example,  in 
order  to  handle  the  "execute  at  least  once"  loops  (e.g.  repeat- 
until,  and  the  FCRTRAN-66  DO-loop)  a  new  feature  must  be  added  to 
the  it-ti  construct  (see  the  repeat-loop  implementation,  above): 
associate  with  each  it-ti  an  'init'  variable  that  is  true  only  on 
the  first  iteration.  "  And  to  prevent  unnecessary  evaluation  of 
the  boolean  'b'  in  this  structure,  we  must  also  require  condi- 
tional evaluation  of  boolean  expressions  (probably  not  an  unrea- 
sonable requirement,  but  one  forced  on  us  by  the  structure  of  the 
it-ti ,  nevertheless). 

Mote  also  that  the  it-ti  does  not  provide  for  efficient 
implementation  of  the  case-statement.  Without  further  enhance- 
ment, the  it-ti  deprives  us  of  access  to  jump-table  or  hash-table 
implementation  of  selection  constructs.  The  straightforward  if- 
then-elseif  approach  to  selection  is  not  appropriate  for  all  con- 
texts. 

Furthermore,  practically  speaking,  the  it-ti  is  not  one  con- 
trol structure  but  a  family  of  control  structures.  Unlike  a  con- 
ventional repeat  or  while  in  which  we  know  the  control  flow 
entailed  by  the  structure  without  knowing  the  details  of  the 
code,  the  introductory  keyword  of  the  it-ti  does  not  give  us  any 
information  about  the  control  flow  of  the  following  code.  It 
simply  announces  that  a  section  of  code  has  been  reached  which 
will  contain  alterations  to  sequential  control  flow.  The  reader 
will  have  to  examine  the  body  of  each  it-ti  to  understand  the 
nature  of  the  control  flow.  This  criticism  can  be  made  concrete 
by  observing  that  the  'traditional'  control  structures  have  a 
topologically  constant  flow  chart  representation  as  shown  in  Fig- 
ures 1-5* 
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?isure  1  .     If-then-else 


pi^ure  2.     Case  statement 


i  :=  1    to  n 


body 


I 


Figure  3-  For-loop 


1 


^  oody 


Figure  4.  Repeat-loop 


body 


F 


OR 


T 


Figure  5.  While-loop 


No  matter  what  'b',  'x',  or  'body'  may  be,  the  characteristics  of 
the  traditional  control  structures  can  be  captured  with  a  single 
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••-       .      r  the     -  uct,  ~i;ere  is  no 

•  flow  •-    '  r  the  it-ti.  About  the  best  that  can 

be  lone  is  to  indicate  a  pseudo-decision  node  at  the  end  of  each 
guard  clause: 


Figure  5.  it-ti 

They  are  not  true  decision  nodes  because  there  is  no  run-time 
decision  to  repeat  or  break:  the  programmer  makes  that  decision 
at  iesisn  time. 


iince  an  i 
graphs,  a  large 
to  satisfy  the 
hope  that  thi 
improvement  in 
'simple'  ones, 
(from  Knuth  [3] 
Dijkstra  called 
(see  Figure  7) • 


-ti  with  N  guard  clauses  has  2**N  possible  flow- 

it-ti,  can  be  quite  complex  and  obscure,  and  fail 

need  for  readable,  maintainable  code.   One  would 

s  additional  complexity  would  be  justified  by  an 

our  ability  to  express  algorithms,  especially 

But,  there  is  still  a  simple  control  flow  graph 

)  that  the  it-ti  cannot  handle  without  contortion. 

it  the  Iootd  that  is  executed  "n  and  a  half  times" 


1 


]* 


1 

Figure  7-  Dijkstra's  n-and-a-half -times  loop 

If  3  is  empty  we  have  a  while  loop,  and  if  T  is  empty  we  have  a 
repeat  loop.   In  spite  of  the  fact  that  the  it-ti  allows  us  to 
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hand-craft  a  control  structure  to  meet  our  needs,  the  "n  and  a 
half  times  loop"  does  not  have  a  simple  implementation  using  it. 
About  the  best  we  can  do  is  to  duplicate  3,  or  introduce  a 
boolean  variable. 


S; 

it 


ti 


->  T;  3;  repeat; 
true  ->  break; 


toggle  :=  true; 

toggle  ->  3;  toggle  : 
b     ->  T;  toggle  : 
true   ->  break; 
ti 


=  false;  repeat; 
=  true;  repeat; 


This  relatively  simple  control-flew  graph  can  be  implemented  with 
an  it-ti  if  we  make  a  further  extension  to  the  construct .  If  we 
allow  continue  (fall  through  to  the  next  guarded  statement)  as  an 
alternative  to  break  or  repeat  then 


true  ->  S;  continue; 
b    ->  T;  repeat; 
true  ->    break; 


ti 


would  do  precisely  what  we  wanted.  However,  continue,  like  the 
init  variable  introduced  earlier,  is  not  clean  and  is  very  ad  hoc 
in  nature.  It  increases  the  complexity  of  the  construct  "[there 
are  now  3**N  possible  flow  graphs)  and  does  not "enhance  the  visi- 
bility of  the  code. 

And  now,  in  order  to  implement  intuitively  simple  programs, 
we  find  ourselves  going  through  the  same  contortions  with  the 
it-ti  that  we  have  gone  through  with  traditional  programming 
structures . 


_a_ 


Before  we  reject  the  it-ti  entirely,  however,  let  us  look  at  one 
context  in  which  the  it-ti  has  proven  effective. 

Veteran  LISP  programmers  may  have  a  feeling  of  ieja-vu  with 
the  it-ti.  In  very  many  ways,  it  resembles  the  cond  conditional 
of  LIS?  except  that  the  cond  does  not  iterate.  ?or  non-veteran 
LISP  programmers,  a  short  discussion  of  the  control-flew  struc- 
tures of  LISP  follows. 

4.1  -ISP  functions 

In  most  programming  languages,  a  function  is  called  with  syntax 
that  looks  something  like 

funcname  ( parml ,  parm2 ,  . . . ) 

A  LISP  function  application  looks  like: 

(funcname  parml  parm2  ...) 

4.2  cond 

The  syntax  of  LISP's  control  structure  for  conditional  execution, 
the  cond,  is  as  follows. 

'cond  (r>1  s1  ) 
(p2  s2) 


(pn  sn) 
) 

The  pi  are  predicate  expressions  evaluating  to  the  LISP 
equivalents  of  true  or  false.  The  pi  are  executed  sequentially 
until  one  of  them,  say  pj ,  evaluates  to  true.  At  that  point,  the 
list  of  statements  sj  is  evaluated.  When  all  of  the  statements 
in  statement  list  sj  are  evaluated,  interpretation  commences  at 
the  first  program  statement  after  the  final  parenthesis  of  the 
cond. 

4.3  prog 

McCarthy  [7]  reports  that  he  originally  intended  that  LISP  would 
he  a  FORTRAN-like  list  processing  language  with  the  addition  of 
recursion  and  conditional  evaluation  of  boolean  expressions.  He 
also  admits  that  prog  looks  like  an  "afterthought",  and  that  its 
design  was  an  "afterthought".  But  it  is  this  control  structure 
that  provides  iteration  via  labels  and  go.  If  we  assume  that 
(A  n)  is  a  function  that  returns  the  nth  element  of  the  array  A, 
then  the  array  search  problem  could  be  written  in  LISP  as  fol- 
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(prog  (index) 

(setq  index  1 ) 

loop    ;this  is  just  a  label,  not  a  LISP  keyword 

(cond  ((greaterp  index  (sizeof  A))  (go  notfound)) 
((equal  (A  index)  K)  (go  found)) 

(setq  index  (addl  index)) 
(50   loop) 
notfound 

(:i  k) 

( return ) 
found 

(?  index) 

( return ) 
) 

A  more  efficient  LISP  program  to  perform  this  search  would  be: 

(prog  (index) 

(setq  index  1 ) 
loop 

(cond  ((greaterp  index  'sizeof  A))  (N  K)  return) 

((eaual  (A  index)  K)        (F  index)  return) 

(setq  index  (addl  index)) 
(go  Iootd) 

) 

One  can  see  that  this  transliteration  from  our  pidgin-code  into 
LISP  results  in  FGRTRAN-like  code  which,  when  one  thinks  about 
it,  is  a  far  cry  from  the  programming  style  indicated  by  the  rest 
of  the  LISP  language:  this  goto  style  of  programming  is  an  abdi- 
cation of  the  applicative  nature  of  LISP. 


5-  An  alternative  to  prog 

A  moment's  thought  will  convince  you  that  it  is  easy  enough  to 
incorporate  the  it-ti  construct  into  LISP.  The  syntax  of  the 
cond  is  modified  to  accept  one  of  the  keywords  break  or  repeat  at 
the  end  of  the  statement  list.  The  keyword  break  specifies  that 
control  exits  the  cond.  The  keyword  repeat  specifies  that  the 
cond  is  to  be  repeated.  I.e., 


'cond  (p1  s1  r repeat /break _ 
(p2  s2  [repeat /break _ 


(pn  sn  [repeat /break]) 

There  are  some  differences  between  the  enhanced  cond  in  Navlisp 
and   Parnas '   strict  definition  of  the  it-ti .   7or  uioward 
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.ity  with  current  implementations  LISP, 
repeat /break  is  optional  since  the  conventional  conti  is  defined 
as  if  break  were  at  the  end  of  each  statement  list.  And  for  the 
same  reason,  the  cond  does  not  abort  if  all  of  the 
guards/predicates  are  false.  Unfortunately,  this  results  in  the 
loss  of  one  of  the  distinct  advantages  of  the  it-ti:  providing  an 
effective  run  time  check  that  each  case  has  been  anticipated. 

With  this  enhancement  to  cond,  the  coding  of  our  example  is 
concise: 

(setq  index  1  ) 

( cond 

((greaterp  index  (sizeof  A))  (N  X)  break) 

((equal  (A  index)  K)        (P  index)  break) 

(T  (setq  index  (addl  index))  repeat) 

) 

Note  -again  that  the  keyword  break  is  not  necessary  since  that  is 
the  default  action  of  the  LISP  cond. 

5-1   Examples 

Winston  [5],  page  323,  defines  a  non-recursive  factorial  function 
which  is  reproduced  below: 

(defun  factorial  (n)         ;  written  in  Maclisp 
(prog  (result  counter) 
(setq  result  1 ) 
(setq  counter  n) 

loop  ;  note  the  label 

(cond  ((zerop  counter)  (return  result))) 
(setq  result  (times  counter  result)) 
(setq  counter  (subl  counter)) 
(go  loop))) 

The  following  shows  the  result  of  defining  the  function  using  the 
modified  cond. 

(defun  factorial  (n)         ;  written  in  Navlisp 
(let  ((result  1)  (counter  n)) 

(cond  ((zerop  counter)  result  break) 

(T  (setq  result  (times  counter  result)) 
(setq  counter  (subl  counter)) 
repeat ) ) ) ) 

The  let  used  in  the  above  example  is  a  LISP  function  which,  like 
the  begin  of  Algol  and  the  curly  brace  ' { '  of  C ,  defines  an 
environment  with  local  variables.  That  is,  let  is  simply  a  prog 
without  the  complications  of  labels,  gc_,  and  return.  In  Maclisp, 
let,  prog,  and  an  unmodified  cond  are  available.  In  Navlisp, 
only  the  let  and  the  enhanced  cond  are  necessary. 
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McCarthy  [6],  rage  25,  illustrates  the  use  of  prog  with  a 
program  to  compute  the  length  of  a  list,  lis  version  of  this 
function  uses  prog: 

(defun  length  (list) 
(prog  (u  v) 

(setq  v  0) 
(setq  u  list) 
a  (cond  ((null  u)  'return  v 
'setq  u  (cdr  u) ) 
(seta  v  (addl  v)) 
(go  a)  )) 

The  following  is  a  version  using  the  modified  cond. 

(defun  length  (list) 

(let  ((v  0)  (u  list)) 

(cond  ((null  u)  v  break) 
(T  (setq  u  (cdr  u)) 
(setq  v  (addl  v) ) 
repeat ) ) ) ) 

A  more  intricate  example  comes  from  Winston  [5],  page  334.  If  we 
assume  that  (matrix  i  j)  is  a  function  that  returns  the  (i,j) 
element  from  a  two-dimensional  array  named  matrix,  then  Winton's 
version  using  prog  is: 

(defun  print-matrix  (n  m)      ;  written  in  Maclisp 
(prog  (i  j) 

(setq  i  C) 

row-loop 

(cond  ((equal  i  n)  (return  nil))) 

(terpri)  ;  prints  an  end-of-line 

(setq  j  0) 

column-loop 

(cond  ((equal  j  m)  (go  next-row))) 

(princ  (matrix  i  j)) 

(princ  ' |  | )        ;  prints  a  blank 

(setq  j  (addl  j)) 

(go  column-loop) 

next-row 

(setq  i  (addl  i)) 

(go  row-loop))) 

This  program  prints  out  the  elements  of  a  two-dimensional  array  a 
row  at  a  time.  The  following  is  the  Navlisp  equivalent  using  the 
it-ti  form  of  cond: 


-13- 


' cond  ( ( null  c )  break ) 


■\in  print-matrix  n       ;  written  in  ITavlisp 
(let  ((i  0)  (j))   ;  i  is  not  initialized 
(cond  ((equal  i  n)  nil  break) 
(T  (terpri) 
(setq  j  0) 
(cond  ((equal  j  m)  break) 

T  (printf  (matrix  i  j)  "  ") 
(setq  i  (addl  j)) 
reneat ; ) 
(setq  i  (addl  i)) 
repeat ) ) ) ) 

Our  final  example  is  the  LISP  interpreter  function  eve  on  coded  in 
Navlisp. 

(defun  evcon  (beg  a) 
(let  ((c  beg) ' 

(< 

((eval  (caar  c)  a) 

(let  ((slist  (cdar  c))  (s  (car  (cdar  c)))) 
(cond  ((null  s)  (set  'c  (cdr  c))  break) 
( ( atom  s ) 

(cond  ((equal  s  'repeat)  (set  'c  beg) 
break) 
((equal  s  'break  )  (set  'c  nil) 

break) 
(T  (eval  s  a) 

(set  'c  (cdr  c) ) 
break) ) 
break) 
(T  (eval  s  a) 

(set  'slist  (cdr  slist)) 

(set  's  (cond  ((not  (null  slist)) 

(car  slist) ) ) ) 
repeat ) ) ) 
repeat ) 
( T  ( set  ' c  ( cdr  c ) )  repeat ) 
)     )) 


6.  Conclusions 

Computer  Science  .as  a  field  is  always  on  the  lookout  for  program- 
ming concepts  that  simplify  the  art  of  programming.  Parnas'  it- 
ti_  is  an  interesting  proposal  to  that  end,  but  does  have  several 
serious  drawbacks.  However,  the  it-ti  has  proved  itself  a  very 
apt  programming  structure  for  LISP,  allowing  the  complex  prog  to 
be  replaced  by  an  enhancement  to  cond.  The  new  cond  is  slightly 
more  complicated  than  the  old,  but  allows  the  writing  of  itera- 
tive programs  whose  structures  are  more  within  the  programming 
spirit  of  LISP.  This  structure  has  been  implemented  in  Navlisp 
and  has  Droved  itself  to  be  both  conroact*  and  sufficient. 
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Appendix 

In  [2],  Dijkstra  develops  a  programming  language  conducive  to 
correctness  proofs  in  which  he  defines  two  constructs  he  calls 
if-fi  and  do-od •  He  introduces  the  concept  of  the  'weakest 
precondition',  written  wp(S,R)  and  paraphrased  as  'The  necessary 
conditions  which  guarantee  that  execution  of  statement  3  will 
leave  the  compulation  in  state  ?..'  Parnas  [1]  cites  Dijkstra  i'21 
as  his  inspiration  for  the  it-ti ,  noting  that  it  is  a  modifica- 
tion of  the  do-od  and  the  if-fi .  He  does  not,  however,  attempt 
to  apply  Dijkstra 's  'weakest  precondition'  to  the  it-ti .  For 
completeness,  it  is  included  here.  The  reader  is  referred  to  [2] 
for  a  complete  discussion  of  the  development  of  the  weakest 
precondition  for  the  do-od  and  if-fi .  It  should  also  be  noted 
that  the  following  discussion  assumes  non-determinacy,  as  do 
Dijkstra  and  Parnas. 

Let  IT  refer  to  the  it-ti: 

it 

31  ->  31 
B2  ->  32 


En  ->  3n 
ti 

where  the  last  statement  in  each  Si  is  either  break  or  repeat. 
At  least  one  of  the  Ei  will  evaluate  to  true  (otherwise  the 
results  are  -undefined  and  will  abort  execution  of  the  program) . 
That  is,  using  the  notation  in  [2]**: 

(Si  :  1  <=  i  <=  n  :  Bi) 

Since  the  construct  is  non-deterministic,  we  can  re-arrange  the 
statements  such  that: 


(Em  :  (0  <=  m  <=  n)  : 

(Ai  :  ["0  <=  i  <=  m)  and  (Si  ends  with  'repeat' 
or  [(in  <=  i  <=  n)  and  (Si  ends  with  'break') 


)) 


If  m  =  0  then  the  construct  corresponds  to  Dijkstra 's  if-fi ,  and 
if  m  =  n  the  construct  is  an  infinite  loop.  This  is  effectively 
equivalent  to  the  following: 


*  It  may  interest  some  to  know  that  it  required  only  six 
additional  lines  of  C- code  to  the  Mavlisp  interpreter  to 
implement  the  enhanced  cond. 

*~*  The  notation  uses  Ei  to  mean  'there  exists  an  i',  and  Ai  to 
mean  ' for  all  i ' . 
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1c 

31   -> 

" 

32  -> 

52 

Bm  -> 

Sm 

)d 

Lf 

B(m+1  : 

)   -> 

S(m+1 

Bn 

-> 

3n 

true 

-> 

error 

fi 

(The  lasT;  statement  of  the  if  is  necessary  if  m  =  n.)  Note  that 
this  assumes  that  for  any  iteration  either 

(Ai  :  Bi  :  (Aj  :  Bj  :  [i  in  (1 ,m)   and  j  in  (1,m)] 

or  [i  in  (m+1 ,n)  and  j  in  (m+1,n)]  )) 

or  that  do-od/repeat  statements  take  precedence  over  if-fi /break 
statements  if  more  than  one  Ei  is  true.  With  these  qualifica- 
tions on  the  it-ti  we  can  arrive  at  its  weakest  precondition. 
Let  DO'  represent  that  sub-part  of  the  it-ti  that  repeats ,  and 
IF'  represent  that  sub-part  of  the  it-ti  that  creaks ,  then 

wp(IT,R)  =wp(DO',  wp(I?',R)  ) 

where  (from  [2]) 

wp(n",R)  =  (Ej  :  m  <  j  <=  n  :  Bj)  and 

(Aj  :  m  <  i  <=  n  :  Bj  =>  wp(Sj,R)) 

wp(D0',R)  =  (Ek  :  k  >=  0  :  Hk(R)) 

Hk(R)  =  wp(IF,  H(k-1)(R))  or  H(k-1)(R) 

HO(R)  =  R  and  not  (Sj  :  1  <=  j  <=  m  :  Bj) 
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